Amazon EC2 CentOS 7 AMIファーストインプレッション
ども、大瀧です。
マッツォさんの以下のツイートで、CentOS 7のAMI(しかもHVM)がリリースされていることを知りました。
CentOS7のHVM AMIが出ました！ RT CentOS 7 (x86_64) with Updates HVM on AWS Marketplace https://t.co/OOVN3WGKYN
— MATSUO a.k.a マッツォ (@understeer) October 8, 2014
Marketplaceの以下のページから起動できます。
CentOS 6のAMIとどの辺りが異なるのか、触ってみた感想を記します。
HVMとは
AMI(Amazon Machine Image)にはPV(準仮想化)とHVM(完全仮想化)の2つの形式があり、相互の互換性はありません。今回提供されるのはHVMのAMIです。形式よって実行できるEC2インスタンスタイプが異なり、最近追加された新しい世代のタイプはHVMでのサポートが良好ですので、自然な選択と言えるでしょう。旧世代のタイプ(t1.*、m1.*、c1.*)で使えないことにご注意ください。
デフォルトユーザーがcentosになった
CentOS 6 AMIでは、デフォルトユーザー(rootユーザー以外の準システムユーザー)はなしで、rootユーザーにキーペアの公開鍵が登録されていました。CentOS 7 AMIではcentosユーザーがデフォルトユーザーになります。rootユーザーでアクセスしないように注意しましょう。
EPELリポジトリがスマートに使える
つい最近、CentOSのextrasリポジトリにepel-releaseパッケージが追加されました。今回のCentOS AMIでも取得できますので、今までのrpmコマンドベタ打ちよりもスマートにEPELリポジトリが導入できます。
$ sudo yum install epel-release 読み込んだプラグイン:fastestmirror Loading mirror speeds from cached hostfile * base: www.ftp.ne.jp * extras: www.ftp.ne.jp * updates: www.ftp.ne.jp パッケージ epel は利用できません。 エラー: 何もしません [centos@ip-172-31-16-29 network-scripts]$ sudo yum install epel-release 読み込んだプラグイン:fastestmirror Loading mirror speeds from cached hostfile * base: www.ftp.ne.jp * extras: www.ftp.ne.jp * updates: www.ftp.ne.jp 依存性の解決をしています --> トランザクションの確認を実行しています。 ---> パッケージ epel-release.noarch 0:7-2 を インストール --> 依存性解決を終了しました。 依存性を解決しました ==================================================================================================================================================== Package アーキテクチャー バージョン リポジトリー 容量 ==================================================================================================================================================== インストール中: epel-release noarch 7-2 extras 13 k トランザクションの要約 ==================================================================================================================================================== インストール 1 パッケージ 総ダウンロード容量: 13 k インストール容量: 22 k Is this ok [y/d/N]: y Downloading packages: epel-release-7-2.noarch.rpm | 13 kB 00:00:00 Running transaction check Running transaction test Transaction test succeeded Running transaction インストール中 : epel-release-7-2.noarch 1/1 検証中 : epel-release-7-2.noarch 1/1 インストール: epel-release.noarch 0:7-2 完了しました! $
パッケージによって追加されるyumリポジトリの設定ファイルではenabled=1になっているので、オプションなしでEPELリポジトリのパッケージが扱えます。試しにansibleパッケージを導入してみます。
$ sudo yum install ansible 読み込んだプラグイン:fastestmirror Loading mirror speeds from cached hostfile * base: www.ftp.ne.jp * epel: ftp.kddilabs.jp * extras: www.ftp.ne.jp * updates: www.ftp.ne.jp 依存性の解決をしています --> トランザクションの確認を実行しています。 ---> パッケージ ansible.noarch 0:1.7.1-1.el7 を インストール --> 依存性の処理をしています: python-paramiko のパッケージ: ansible-1.7.1-1.el7.noarch --> 依存性の処理をしています: python-keyczar のパッケージ: ansible-1.7.1-1.el7.noarch --> 依存性の処理をしています: python-jinja2 のパッケージ: ansible-1.7.1-1.el7.noarch --> 依存性の処理をしています: python-httplib2 のパッケージ: ansible-1.7.1-1.el7.noarch --> トランザクションの確認を実行しています。 ---> パッケージ python-httplib2.noarch 0:0.7.7-3.el7 を インストール ---> パッケージ python-jinja2.noarch 0:2.7.2-2.el7 を インストール --> 依存性の処理をしています: python-babel >= 0.8 のパッケージ: python-jinja2-2.7.2-2.el7.noarch --> 依存性の処理をしています: python-markupsafe のパッケージ: python-jinja2-2.7.2-2.el7.noarch ---> パッケージ python-keyczar.noarch 0:0.71c-2.el7 を インストール --> 依存性の処理をしています: python-pyasn1 のパッケージ: python-keyczar-0.71c-2.el7.noarch --> 依存性の処理をしています: python-crypto のパッケージ: python-keyczar-0.71c-2.el7.noarch ---> パッケージ python-paramiko.noarch 0:1.12.4-1.el7.centos を インストール --> 依存性の処理をしています: python-ecdsa のパッケージ: python-paramiko-1.12.4-1.el7.centos.noarch --> トランザクションの確認を実行しています。 ---> パッケージ python-babel.noarch 0:0.9.6-8.el7 を インストール ---> パッケージ python-crypto.x86_64 0:2.6.1-1.el7.centos を インストール ---> パッケージ python-ecdsa.noarch 0:0.11-3.el7.centos を インストール ---> パッケージ python-markupsafe.x86_64 0:0.11-10.el7 を インストール ---> パッケージ python-pyasn1.noarch 0:0.1.6-2.el7 を インストール --> 依存性解決を終了しました。 依存性を解決しました ==================================================================================================================================================== Package アーキテクチャー バージョン リポジトリー 容量 ==================================================================================================================================================== インストール中: ansible noarch 1.7.1-1.el7 epel 854 k 依存性関連でのインストールをします: python-babel noarch 0.9.6-8.el7 base 1.4 M python-crypto x86_64 2.6.1-1.el7.centos extras 470 k python-ecdsa noarch 0.11-3.el7.centos extras 69 k python-httplib2 noarch 0.7.7-3.el7 epel 70 k python-jinja2 noarch 2.7.2-2.el7 base 515 k python-keyczar noarch 0.71c-2.el7 epel 218 k python-markupsafe x86_64 0.11-10.el7 base 25 k python-paramiko noarch 1.12.4-1.el7.centos extras 900 k python-pyasn1 noarch 0.1.6-2.el7 base 91 k トランザクションの要約 ==================================================================================================================================================== インストール 1 パッケージ (+9 個の依存関係のパッケージ) 総ダウンロード容量: 4.5 M インストール容量: 20 M Is this ok [y/d/N]: y (略) インストール: ansible.noarch 0:1.7.1-1.el7 依存性関連をインストールしました: python-babel.noarch 0:0.9.6-8.el7 python-crypto.x86_64 0:2.6.1-1.el7.centos python-ecdsa.noarch 0:0.11-3.el7.centos python-httplib2.noarch 0:0.7.7-3.el7 python-jinja2.noarch 0:2.7.2-2.el7 python-keyczar.noarch 0:0.71c-2.el7 python-markupsafe.x86_64 0:0.11-10.el7 python-paramiko.noarch 0:1.12.4-1.el7.centos python-pyasn1.noarch 0:0.1.6-2.el7 完了しました! $
いい感じですね！
cloud-initはインストール済み
CentOS 6 AMIでは、cloud-initパッケージはEPELリポジトリに収録され、デフォルトではインストールされませんでした。インストールすればいいと言えばそれまでなのですが、標準AMIからUser Dataによるブートストラップ処理ができないのは地味に使い勝手が悪かった印象です。今回のAMIでは、既にインストール済みでこちらもいい感じです。
$ rpm -q cloud-init cloud-init-0.7.5-10.el7.centos.1.x86_64 $
インスタンスストア自動マウントのマウントポイントは/mnt
cloud-initがインストール済みなので、それに付随してインスタンスストアの1本目(Instance Store 0)が/mntに自動でマウントされます。実際には、インスタンス起動時にcloud-initによって/etc/fstabファイルの末尾に以下のエントリーが追加されます(デバイス名はインスタンス作成時の設定に連動します)。
/dev/xvdb /mnt auto defaults,nofail,comment=cloudconfig 0 2
Amazon Linuxの/media/ephemeral0とは異なることに注意しましょう。...2本目のインスタンスストアのマウントポイントをどうするか、悩む設定ですねwもちろん、/etc/fstabを変更すれば任意のマウントポイントに変更することは可能です。
ディスクデバイス名の対応がすっきりした
CentOS 6 AMIではルートディスク(EBS)のデバイス名のマッピングが独特で、Management Consoleのデバイス名と差異がありました。CentOS 7 AMIではルートディスクは/dev/sda1(OSからは/dev/xvda1で認識)になり、追加ディスクもEC2作成時の設定通りに認識され、わかりやすくなりました。以下は、c3.largeでインスタンスストア2本(sdb,sdc)と追加EBS1本(sdd)を構成したインスタンスでの例です。
$ sudo fdisk -l Disk /dev/xvda: 8589 MB, 8589934592 bytes, 16777216 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト Disk label type: dos ディスク識別子: 0x000aec37 デバイス ブート 始点 終点 ブロック Id システム /dev/xvda1 * 2048 16777215 8387584 83 Linux Disk /dev/xvdb: 16.4 GB, 16380329984 bytes, 31992832 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト Disk /dev/xvdc: 16.4 GB, 16380329984 bytes, 31992832 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト Disk /dev/xvdd: 8589 MB, 8589934592 bytes, 16777216 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト $
まとめ
いかがでしたでしょうか。CentOS 6のAMIでクセがあった点がかなり改善されており、Amazon LinuxやRHELなど一般的なRed Hat系LinuxのAMIと違和感なく扱えるようになったと思います。Marketplace経由でなく直接起動できるようになるとMarketplaceの制限に悩むこともなくなりより良いのではと思います。
まだ本番投入されるには時間がかかるかもしれませんが、近いうちにスタンダードになるであろうLinux環境に今のうちから慣れておきましょう！
![[小ネタ] Windows AMIの更新通知の購読をAWS CLIから行う](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-daa54df39308ec469607d6a913b81811/3c36486880ec490db06f2c3f36080c43/amazon-sns)
